You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(desktop): wait for the server's database upgrade instead of reporting a failed start - #35056
Cause: the desktop gives the backend a fixed readiness budget (3 min on main) and then reports 'The server started but did not become ready in time.' Long upgrade migrations block the server's main thread and the server logged nothing until all migrations finished, so the desktop could not tell a migrating backend from a stuck one. Fix: (1) runMigrations in apps/server/src/persistence/Migrations.ts now logs 'Running database migrations' at info level before running when hasPendingMigrations() is true; the existing 'Migrations ran successfully' line marks the end. Both strings live in a new shared module, packages/shared/src/databaseMigrationLog.ts (exported as @t3tools/shared/databaseMigrationLog), with isRunningDatabaseMigrations(output), which is true when the last start line comes after the last finish line. (2) In DesktopBackendManager, onReadinessFailure checks the output tail it already captures (4,000 chars). While migrations are running it logs a warning and returns without reporting a startup failure, so the existing probe loop keeps waiting and the splash stays up until the server is ready. A crash during a migration still reports through the exit/restart path. After migrations finish, the readiness budget applies as before. Nothing visible changes beyond the false failure screen no longer appearing during a migration. No regex or parser: isRunningDatabaseMigrations is two lastIndexOf calls over a string of at most 4,000 chars, linear time on any input. Reproduction was by unit test, not a rerun of the 3-minute Electron run from the report: the extended slow-startup test fails on main (report emitted while the backend's last line is the start line) and passes with the fix. I did not run the full desktop app end to end with the fix.
Commit b68aedf (origin/main). Built the desktop (apps/desktop vp run build; the Linux browser-secret helper was replaced with a placeholder binary because libsecret-1-dev is missing on the VM, which does not touch backend startup). Under headless-desktop I launched electron dist-electron/main.cjs --no-sandbox --disable-gpu with T3CODE_HOME set to a fresh empty directory, found the spawned backend child and sent it SIGSTOP about 7 s after launch. This simulates the reporter's backend: alive, writing no output, not answering readiness while a 5-minute migration runs. Screenshots: 20 s, 70 s and 175 s showed the T3 splash. 190 s showed 'T3 Code could not start / The server started but did not become ready in time. / The server wrote no output.' The desktop trace recorded 'Timed out after 180000ms'. I sent SIGCONT at 200 s; by 215 s the window had opened to the Welcome screen by itself. So on main the false failure screen appears at 3 minutes (60 s in 0.1.6), and the reporter's upgrade needed about 5m17s (migration 72 alone took 4m45s on their 12.5 GB statev2.sqlite).
Evidence
Being captured: before and after in the real app. This section is filled in before the pull request can merge.
Tests
apps/desktop: vp test run src/backend/DesktopBackendManager.test.ts -> 12 passed. The extended 'waits out a slow startup...' case fails with the desktop fix stashed (assertion at the migrating-backend poll) and passes with it. apps/server: vp test run src/persistence/Migrations.test.ts src/persistence/Sqlite.test.ts -> 15 passed. Real server on a fresh --base-dir: printed 'INFO Running database migrations' then 'INFO Migrations ran successfully' at default log level; a second start on the same home printed no migration lines. vp run check:changed -> all pass (format, lint, knip, typecheck of 41 packages, tests of 3 changed files).
Not in this change
The fixed 3-minute DEFAULT_BACKEND_READINESS_TIMEOUT itself is unchanged.
The splash does not say a database upgrade is in progress; it stays on the existing starting state.
The Effect Migrator logs each 'Running migration' at debug level; per-migration progress at info level was not added.
Migration 072 (partial index over turn_items) taking minutes on very large databases was not optimized.
AI-assisted; verified with the tests and tools listed above.
…ting a failed start
The desktop gave the backend a fixed readiness budget and then showed
"could not start". Long upgrade migrations on large databases outlast it,
and the server printed nothing while migrating, so the app reported a false
failure and users quit mid-migration.
The server now logs "Running database migrations" before pending migrations
run. While that is the backend's latest migration line, the desktop keeps
waiting instead of reporting a readiness failure. A crash still reports
through the exit path.
AI-assisted; verified with the tests and tools listed above.
Macroscope's review found this PR approvable — The desktop now recognizes ongoing database migrations and avoids prematurely reporting a failed startup. Existing readiness retries and process-exit handling remain unchanged, with no changes to migration execution or schema contents.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The server now logs shared database migration start and finish markers. During backend readiness checks, the desktop manager uses captured output to detect active migrations and defer startup failure handling. Tests cover active and completed migrations.
Changes: Migration-aware startup
Layer / File(s)
Summary
Shared migration markers and server logging packages/shared/src/databaseMigrationLog.ts, packages/shared/package.json, apps/server/src/persistence/Migrations.ts
Shared code defines migration start and finish messages and checks which occurred last. The migration runner logs the shared markers.
Desktop readiness handling and tests apps/desktop/src/backend/DesktopBackendManager.ts, apps/desktop/src/backend/DesktopBackendManager.test.ts
When output indicates an active migration, the desktop manager logs a warning and returns before reporting startup failure or persisting a failure snapshot. Tests cover active migrations, completed migrations, and readiness after HTTP 200.
sequenceDiagram
participant MigrationRunner
participant DesktopBackendManager
participant MigrationLogCheck
MigrationRunner->>DesktopBackendManager: captured output with migration markers
DesktopBackendManager->>MigrationLogCheck: check captured output
MigrationLogCheck-->>DesktopBackendManager: active migration status
DesktopBackendManager-->>DesktopBackendManager: defer readiness failure handling
Loading
Possibly related PRs
pingdotgg/t3code#26247: Changes the managed backend readiness budget and tests the existing startup timeout, which this change also exercises.
Suggested reviewers:shivamhwp, macroscopeapp
Merge Risk: Low · up to b91e8
This fix removes the false startup failure for long database upgrades. A rare timing edge case remains: if the upgrade finishes just before the readiness window ends, the app can still report a failed start. This is a bounded residual risk and does not block merging.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the main change: the desktop app now waits for the server's database upgrade instead of reporting a failed start. The raw summary shows the migration-aware readiness check in DesktopBa…
Description check
The description follows the template's sections and explains the problem, the change, and the verification. It gives a reproduction on main, specific test results, and a clear list of what is excluded…
Linked Issues check
[#29516] The issue states only that the desktop app does not start on Windows 0.1.6 and that the expected behavior is to start. It has no logs and no acceptance criteria. The PR attributes the failure…
Out of Scope Changes check
All changed files support the single objective of waiting for database migrations during desktop startup. packages/shared/src/databaseMigrationLog.ts holds the shared start and finish strings and the …
Full details: Title check
Explanation
The title names the main change: the desktop app now waits for the server's database upgrade instead of reporting a failed start. The raw summary shows the migration-aware readiness check in DesktopBackendManager and the migration start/finish logging, which match this. The title follows the conventional commit form the template asks for.
Full details: Description check
Explanation
The description follows the template's sections and explains the problem, the change, and the verification. It gives a reproduction on main, specific test results, and a clear list of what is excluded. Two gaps remain. The Scope section does not link a bug issue in the template's form, though the description does say 'Fixes #29516'. The Evidence section says 'Being captured' and has no before/after screenshots or recording, even though the template asks for them for UI-visible behavior. The template also asks for the model and harness used when an agent was involved. The author says 'AI-assisted' but does not name the model or harness. These are non-critical gaps; the description is mostly complete.
Full details: Linked Issues check
Explanation
[#29516] The issue states only that the desktop app does not start on Windows 0.1.6 and that the expected behavior is to start. It has no logs and no acceptance criteria. The PR attributes the failure to a database migration that outlasts the fixed readiness budget. The reviewed diff addresses that path: apps/server/src/persistence/Migrations.ts logs 'Running database migrations' when hasPendingMigrations() is true, and packages/shared/src/databaseMigrationLog.ts exposes isRunningDatabaseMigrations(). DesktopBackendManager.ts onReadinessFailure checks the captured output tail and, while migrations run, logs a warning and does not report a startup failure, so the existing probe loop keeps waiting. The DesktopBackendManager.test.ts cases cover a migrating backend that returns HTTP 503 and then 200, and a case that still reports a timeout after 180 seconds when both migration markers appear. Crash handling stays on the exit/restart path. The cause is inferred from the author's simulated reproduction, not from the reporter's logs, so the link to the reporter's exact failure is unconfirmed. The implemented objective, keeping the app waiting during migrations, is present in the code.
Full details: Out of Scope Changes check
Explanation
All changed files support the single objective of waiting for database migrations during desktop startup. packages/shared/src/databaseMigrationLog.ts holds the shared start and finish strings and the detection function. packages/shared/package.json adds the export that the server and desktop import. apps/server/src/persistence/Migrations.ts emits the start log. apps/desktop/src/backend/DesktopBackendManager.ts applies the startup-failure guard. apps/desktop/src/backend/DesktopBackendManager.test.ts covers that guard. No unrelated behavior change appears in the summarized changes. The summary does not show every line, so this conclusion rests on the whole-PR summary and the listed file changes.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.
The automated pipeline stopped on this pull request and will not merge it:
the capture step could not show the problem on the base commit, so there is nothing to prove fixed.
Built apps/desktop on each commit. Launched electron dist-electron/main.cjs --no-sandbox --disable-gpu with a fresh T3CODE_HOME and T3CODE_DEV_SEED=0. Sent SIGSTOP to the spawned backend at seven seconds, captured around 20, 175 and 190 seconds, sent SIGCONT at 200 seconds, captured after resume, and stopped around 230 seconds. Both backends became HTTP-ready before the seven-second pause. Both recordings showed Welcome past the readiness budget; neither reproduced the reported startup failure. Consequently, the head's slow-migration behavior was not proven. All started apps were stopped and both worktrees and scratch files were removed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:M30-99 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Cause: the desktop gives the backend a fixed readiness budget (3 min on main) and then reports 'The server started but did not become ready in time.' Long upgrade migrations block the server's main thread and the server logged nothing until all migrations finished, so the desktop could not tell a migrating backend from a stuck one. Fix: (1) runMigrations in apps/server/src/persistence/Migrations.ts now logs 'Running database migrations' at info level before running when hasPendingMigrations() is true; the existing 'Migrations ran successfully' line marks the end. Both strings live in a new shared module, packages/shared/src/databaseMigrationLog.ts (exported as @t3tools/shared/databaseMigrationLog), with isRunningDatabaseMigrations(output), which is true when the last start line comes after the last finish line. (2) In DesktopBackendManager, onReadinessFailure checks the output tail it already captures (4,000 chars). While migrations are running it logs a warning and returns without reporting a startup failure, so the existing probe loop keeps waiting and the splash stays up until the server is ready. A crash during a migration still reports through the exit/restart path. After migrations finish, the readiness budget applies as before. Nothing visible changes beyond the false failure screen no longer appearing during a migration. No regex or parser: isRunningDatabaseMigrations is two lastIndexOf calls over a string of at most 4,000 chars, linear time on any input. Reproduction was by unit test, not a rerun of the 3-minute Electron run from the report: the extended slow-startup test fails on main (report emitted while the backend's last line is the start line) and passes with the fix. I did not run the full desktop app end to end with the fix.
Fixes #29516
Reproduction on main
Commit b68aedf (origin/main). Built the desktop (apps/desktop
vp run build; the Linux browser-secret helper was replaced with a placeholder binary because libsecret-1-dev is missing on the VM, which does not touch backend startup). Under headless-desktop I launchedelectron dist-electron/main.cjs --no-sandbox --disable-gpuwith T3CODE_HOME set to a fresh empty directory, found the spawned backend child and sent it SIGSTOP about 7 s after launch. This simulates the reporter's backend: alive, writing no output, not answering readiness while a 5-minute migration runs. Screenshots: 20 s, 70 s and 175 s showed the T3 splash. 190 s showed 'T3 Code could not start / The server started but did not become ready in time. / The server wrote no output.' The desktop trace recorded 'Timed out after 180000ms'. I sent SIGCONT at 200 s; by 215 s the window had opened to the Welcome screen by itself. So on main the false failure screen appears at 3 minutes (60 s in 0.1.6), and the reporter's upgrade needed about 5m17s (migration 72 alone took 4m45s on their 12.5 GB statev2.sqlite).Evidence
Being captured: before and after in the real app. This section is filled in before the pull request can merge.
Tests
apps/desktop: vp test run src/backend/DesktopBackendManager.test.ts -> 12 passed. The extended 'waits out a slow startup...' case fails with the desktop fix stashed (assertion at the migrating-backend poll) and passes with it. apps/server: vp test run src/persistence/Migrations.test.ts src/persistence/Sqlite.test.ts -> 15 passed. Real server on a fresh --base-dir: printed 'INFO Running database migrations' then 'INFO Migrations ran successfully' at default log level; a second start on the same home printed no migration lines. vp run check:changed -> all pass (format, lint, knip, typecheck of 41 packages, tests of 3 changed files).
Not in this change
AI-assisted; verified with the tests and tools listed above.